作者：康子晉｜AWS 解決方案專家，守備範圍橫跨架構設計、維運排錯、成本優化與雲端遷移。
本系列聊一個我最近很有感的主題：怎麼讓 AI 成為團隊裡可靠的一員。

上篇回顧

上一篇，我們用 Steering 幫 AI 寫了一本員工手冊，治好「每次都要重新自我介紹」的失憶。

但手冊有個天生的限制：它是死的。它記得「我是誰、我的規矩、我管哪些帳號」，卻記不住「昨天我們一起熬夜解的那個 bug」。

而我的工作，說穿了就是一堆「昨天發生的事」堆出來的。

先講一個讓我起雞皮疙瘩的瞬間

那是一個普通的下午，我在追一個 Kubernetes 的鬼問題：某個節點上的 pod 怎麼樣都起不來。查了快兩個小時，繞了一大圈，最後發現根因是那台底層的實體機硬體在鬧脾氣，把實例 stop/start 遷到別台健康的機器，問題就好了。當下鬆一口氣，記下來，收工。

結果過沒幾天——同一台節點，又掛了。

換作以前，我得把上次的偵探過程從頭再演一遍：等等，是哪一台來著？上次根因是什麼？我那時候怎麼解的？翻 log、翻筆記、翻聊天紀錄……光是「想起上次發生什麼」就要耗掉十幾分鐘。

但這次我只懶懶地丟了一句：

「這台是不是上次那台？」

AI 秒回：

「對，這台（10.x.x.x）上週出過一模一樣的 pod 問題，當時判定是底層宿主機退化，用 stop/start 遷移解決的。這次建議先確認是不是同一台實體機。」

我盯著螢幕愣了一下。那一刻它不像工具，像一個跟我一起熬過上次那晚、還記得來龍去脈的同事。

這，就是我想要的「動態記憶」。它讓 AI 從每天上班都認不得你的菜鳥，變成那個會說「啊這個我們上次遇過」的老戰友。

老實說，我第一版做得很爛

要讓 AI 記住每天的事，最直覺的做法你大概也想得到：開一個 memory.md，設成 always（每次對話都載入），然後把每天的決定、踩的雷通通往裡面塞。

我一開始就是這樣幹的。然後它就……爆了。

幾個禮拜後，這個檔案胖到快 50 條。問題是它設成 always——意思是我每開一次新對話，這 50 條陳年舊帳就全部塞進去一次。話都還沒講，context 已經被三個禮拜前的瑣事占滿，又慢又燒錢，AI 還因為讀了一堆過期資訊，反而搞不清楚我「最近」在忙什麼。

那陣子我才真的體會到一件事：記憶不是越多越好，是要會「忘」。

你想想人腦嘛。最近的事記得清清楚楚，上個月的只記得個大概，去年的早就剩一個模糊印象了。如果你把這輩子每件事都用同樣的解析度記著，你大概會瘋掉。AI 也一樣。

我的解法：讓記憶像人腦一樣分層

於是我把記憶拆成三層。先講清楚：這是我自己設計的架構，不是 Kiro 內建的功能——但它完全是用 Kiro 的 Steering + Hooks 這兩個現成機制堆出來的。

關鍵就一句話：只有「最近 7 天」這層永遠在線，而且我硬性限制它不准超過 20 條。 再舊的自動往下沉，平常不佔 context；哪天真要考古，再手動把溫層、冷層撈出來。

這樣 AI 每次對話只背「最近一週」的脈絡，輕裝上陣；但歷史一筆都沒丟，只是搬進倉庫了而已。

但分層有個魔鬼細節：誰來搬？

設計畫得很漂亮，可是問題來了——超過 7 天的紀錄，誰負責從熱層搬到溫層？

如果答案是「我每天手動搬」，那我可以跟你保證，這套系統活不過三天。人就是懶，凡是要靠自律手動維護的東西，最後都會死在「啊我今天先不要」。我自己就是這種人，不騙你。

所以我把這件事丟給 Kiro 的 Hook 去自動跑。我設了一個在「每次對話結束」就觸發的 hook，叫 AI 自己做兩件事：把超過 7 天的條目搬到溫層、順便判斷今天有沒有值得記的新事。

官方現行（IDE 1.0）的 hook 長這樣：

{
  "version": "v1",
  "hooks": [
    {
      "name": "auto-memory-sync",
      "trigger": "Stop",
      "action": {
        "type": "agent",
        "prompt": "掃描本次對話：(1) 把 memory.md 中超過 7 天的條目搬到 memory-warm.md (2) 若有值得記的決策或踩雷，精簡寫入 memory.md"
      },
      "enabled": true
    }
  ]
}

trigger: "Stop" 就是「agent 把這一輪講完之後」觸發，action.type: "agent" 代表它跑的是一段 AI 指令而不是 shell 命令。於是每次我跟它聊完、關掉視窗，它自己在背後默默把記憶整理好。隔天我打開，熱層永遠是乾乾淨淨的最近 7 天。

第一次發現它真的「自己整理好了」的時候，我有種養的寵物自己學會上廁所的感動。真的。

小提醒：比較舊版的 Kiro hook 是用 when / then + agentStop 的寫法，IDE 1.0 改成上面這種 trigger / action。功能一樣，欄位名不同而已，別被搞混。

還有一道把關：不是什麼都值得記

自動記錄聽起來很爽，但它有個陷阱：如果每次對話都記，垃圾很快又把它灌爆，等於回到原點。

所以我在那個 hook 的指令裡加了一道門檻，逼它先問自己一句「這事值得記嗎」。只有四種才准記：

• 拍板的決策（最後選了哪個方案）
• 踩到的雷、或是「原本以為對、查證後發現錯」的修正
• 進度里程碑（上線了、交付了）
• 查證後確定的硬結論

至於純操作步驟、閒聊、還沒吵出結果的討論——通通不准記。

這跟現在那些 agent memory 系統一直在強調的「選擇性記憶」其實是同一個道理：記憶的價值在「篩」，不在「囤」。 一個什麼都記的腦袋，跟一個什麼都記不住的腦袋，一樣沒用。

帶走的三個重點

1. 靜態手冊（Steering）救不了「昨天發生的事」，你需要另一套會自己累積的動態記憶。
2. 記憶要分層、要會過期。 最近的永遠在線、久遠的沉進倉庫；不然 always 載入的記憶遲早把 context 撐爆，又慢又貴。
3. 讓它自己整理、還要會挑著記。 靠人手動維護的記憶系統一定會死；自動化加上一道篩選門檻，才撐得久。

到這裡，我的 AI 同事已經「不太唬爛」又「記得住事情」了。但它說到底還是個很會講話的傢伙——它能查文件、能讀我的脈絡，卻還不能真的動手幫我去翻 AWS 帳單、開瀏覽器、戳系統。

下一篇，來聊怎麼幫它長出手腳：MCP。

✍️ 關於作者

康子晉
做 AWS 維運與架構，日常跟一堆帳號、費用、架構圖和客戶為伍。
這個系列記錄我怎麼把 AI 從「會聊天」調教成「能幹活的同事」。

如果這篇對你有幫助，歡迎追蹤這個系列，或來這裡找我聊聊：
🔗 LinkedIn：LinkedIn

第一篇: https://ithelp.ithome.com.tw/articles/10400259
第二篇: https://ithelp.ithome.com.tw/articles/10400274